Typically, controller synthesis and analysis work is done up front prior to programming the controller. The requirements typically include the specification of one or more of the following: operating envelope, operating conditions, sensor uncertainties, actuator uncertainties, plant dynamics, stability and performance (tracking), stability and performance robustness, computation burden (to fit target hardware), redundancy, detection and avoidance of specified faults.
Typically, after synthesis and analysis, various tests such as Hardware-in-the-Loop (HiL), Software-in-the-Loop (SiL), Model-in-the-loop (MiL), X-in-the-loop (XiL) (where X is a generic representation of any piece of the system that will be tested in the loop) tests are performed to validate that the controller and the equipment being controlled are working properly, followed by field evaluations. Once the product is released and in operation, the architecture of the controller is typically fixed (or switches among pre-determined architectures), which may not be adequate.
For example, turbine fuel valves controlled by a controller may exhibit robustness problems in the field, causing the turbine to shut down, or causing the operator to return the failing valve to the manufacturer for inspection. Upon inspection by the manufacturer under controlled conditions, the valve may not show any anomalies and pass End-of-Line (EOL) qualification tests, giving the appearance of nothing wrong with the returned valve. The issue may later be found to be caused by friction whose value is well outside of the normal expected range during the design of the valve. The initial control algorithm may assume a particular friction value in the middle of the expected range. However, when the friction becomes very low or very high, instead of continuing to stabilize the valve, the controller actually tends to excite the mechanical resonant modes and actually becomes part of the problem. This is an example of a problem of controllers, when the plant or equipment physics diverges significantly away from the norm or assumed range.
Robust control theory may fix the above problem by not assuming a nominal plant so that the plant (or equipment) is not required to remain close to nominal during operation. To fix the above problem, a very stiff algorithm is designed to be as insensitive as possible to friction disturbances. Friction is allowed to range from zero to max torque capability of the valve, using a particular industrial implementation of the robust control methodology.
As good as a robust controller is, it can be confused (e.g. have difficulty providing stability and control), like all other controllers, if the basic electro-mechanical physics of the valve (or other equipment) changes or appears to change due to, for example, an undetected position sensor malfunction, undetected blown electronic component or a cyber-attack. There is a long list of events that can confuse controllers. A confused controller is one that is no longer part of the solution of stabilizing and tracking. A confused controller can often also become part of the problem, i.e., where the control actions are actually driving instability.
Confused controllers have been very hard to identify at run time until there is major visible or obvious damage. Confused controllers have typically not been able to self-detect their confusion. What they can detect is whether a pattern in I/O, or a piece of code, matches or mismatches a known identified pattern or model. However, this classical approach to fault detection cannot guard against unanticipated or undetected malfunctions, including those caused by a cyber-attack.